1. Technical Field
The disclosed subject matter relates to techniques providing improved user interfaces for interacting with nested hierarchical data structures, such as those made available via the OMA DM for managing wireless mobile devices as discussed below.
2. Background
The Open Mobile Alliance (OMA) has defined Device Management (DM) mechanisms for performing over-the-air (OTA) access to mobile devices. See “OMA Device Management Protocol, Version 1.2,” Open Mobile Alliance, OMA-TS-DM_Protocol-V1—2 (available via http://www.openmobilealliance.org) and “OMA Device Management Tree and Description,” Open Mobile Alliance, OMA-TS-DMTND-V1—2—1-20080617-A (available via http://www.openmobilealliance.org), both of which are herein incorporated by reference in their entireties. One use of OMA DM is to provide Subscriber Device Management (SDM), whereby a customer service representative (CSR) for a mobile services provider is able to perform over-the-air (OTA) access of device state. Through SDM tools, CSRs are able to remotely resolve customer issues.
Each device that supports OMA DM contains a Management Tree which organizes all available configuration items in the device as a hierarchical tree structure, and is a mechanism by which a management client interacts with the mobile device, e.g. by storing and retrieving values from it and by manipulating the properties of it. A Management Object is a subtree of the Management Tree which is intended to be a (possibly singleton) collection of nodes which are related in some way. For example, the ./DevInfo nodes form a Management Object. A simple Management Object may consist of one single node. Each node within the tree structure can be uniquely addressed with a Uniform Resource Indicator (URI). By identifying nodes with URIs, nodes can be manipulated by management actions carried over the OMA DM protocol.
Although OMA DM defines a protocol and framework that enables OTA management of a wide variety of mobile devices, by design OMA DM does not impose particular requirements as to which Management Objects are provided. As a result, there is variation, across mobile device models and manufacturers, as to which particular Management Objects are available, the format of their data, and their locations throughout the OMA DM tree. An OMA DM Management Tree potentially contains hundreds of Management Objects. This is particularly true where a mobile device is configured to access multiple e-mail accounts and/or paired with multiple Bluetooth devices. The level of detail of an OMA DM, the distribution of the Management Objects throughout a hierarchical data structure, and the variation in the available Management Objects and their locations in the Management Tree across device models and manufacturers, often interfere with a CSR's goal of quick and efficient resolution of customer issues. The OMA DM data-structure is verbose, large, and hard to comprehend. Conventional tools for OMA DM management expose much of the hierarchical nature of the underlying data. Another conventional approach involves creating software customized for the unique OMA DM structures of individual mobile device models. If the provider services a large number of different models of mobile devices, then the provider must have a corresponding large number of customized software programs for CSR interfaces to the OMA DM structures of the various devices. Hence, the use of customized software imposes significant development and maintenance costs, as well as undesired overhead in integrating new products.
CSRs should be able to easily locate relative device information without resorting to Adhoc enumeration methods. CSRs should not be concerned with the underlying hierarchical arrangement information. Also, an effective mechanism for dealing with large lists of similar device settings is necessary.